Subject: NetBIOS connect flows

From: [email-masked] (V.R. Venkataramana)
Date: Wed, 16 Feb 94 13:35:35 PST

Steve Klein responded on Aug 19, 1993 to Scott Adam's Aug 12,1993 mail 
on NETBIOS Connect flows by saying that he will be sending out a proposal 
for a change to the NETBIOS connect sequence. 
   >I will be sending out a proposal for a change to the NETBIOS connect
   >sequence in a day or two.  This proposal will outline changes that
   >IBM is considering for DLSw on the 6611 based on our experiences
   >with NETBIOS applications in the field.  I would like to use this
   >proposal as a starting point for discussions toward the development
   >of a standard that could be adopted by this siglet.
   >
   >Steve Klein
I am really interested in finding out the details of this proposal.  I 
would like to find out if Steve Klein has already posted this proposal 
on some other forum as I cannot find it under "connect.mail" forum. 

I have question on Scott Adam's alternative connect sequence (seen 
from Windows NT) flows:

>>        End Stn 1         DLSw A                DLSw B         End Stn 2
>>        ---------         ------                ------         ---------
>>           |         [DISCONNECTED]       [DISCONNECTED]          |
>>           | Name_Qry(F)   |    NETBIOS_NQ       | Name_Qry(F)    |
>>Note 1.    | ------------> | ------------------> | -------------> |
>>           |         [DISCONNECTED]       [RESOLVE_PEND]          |
>>           |     Name_Rec  |    NETBIOS_NR       |      Name_Rec  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |         [CIRCUT_ESTAB]       [CIRCUIT_PEND]          |
>>           |               |    REACH_ACK        |                |
>>           |               | ------------------> |                |
>>           |               |              [CIRCUIT_ESTAB]         |

From the above flows, it is clear that the NetBIOS "End Stn 1" has to 
issue a NCB.FIND.NAME command before issuing a NCB.CALL command
or as a result of NCB.CALL, DLSw-NetBIOS issues a "FIND.NAME request" 
NetBIOS protocol on the network to find out the MAC address of the 
partner.

As a NetBIOS user, I do not have to issue NCB.FIND.NAME command before
I issue a NCB.CALL to establish a session with remote NetBIOS end station.  
This requirement should not be placed on the NetBIOS end user.  

I would like to find out if the NAME_QUERY (FIND.NAME request)
in the above flow is issued as a result of NetBIOS end station issuing a
NCB.CALL or  as a result of NetBIOS station issuing a NCB.FIND.NAME
command.

Thanks, Venkat
------------------------------- Referenced Note ---------------------------
>From [email-masked]  Thu Aug 19 09:25:53 1993
>Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.239.48.4] with SMTP
>       id AA150668 (for [email-masked], from [email-masked]/[email-masked]); Thu, 19 Aug 93 09:25:53 -0400
>Message-Id: <[email-masked]>
>Received: from RALVMA by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 0922;
>   Thu, 19 Aug 93 09:31:43 EDT
>Date: Thu, 19 Aug 93 09:00:51 EDT
>From: "Steve Klein (254-5623)" <[email-masked]>
>To: [email-masked]
>Subject: Revised NETBIOS connect flows.
>
>Scott, your NETBIOS flows are correct with respect to RFC 1434.>
>In case you are interested in the current 6611 implementation,
>IBM decided to send NETBIOS_NQs and NETBIOS_NRs when a link is in
>CIRCUIT_ESTABLISHED state (see Note 2 and Note 3 of the second flow).
>This change was made after the release of RFC 1434.
>
>I will be sending out a proposal for a change to the NETBIOS connect
>sequence in a day or two.  This proposal will outline changes that
>IBM is considering for DLSw on the 6611 based on our experiences
>with NETBIOS applications in the field.  I would like to use this
>proposal as a starting point for discussions toward the development
>of a standard that could be adopted by this siglet.
>
>Steve Klein
>
>------------------------------ Referenced Note ---------------------------
>>Subject: Revised NETBIOS connect flows.
>>From: [email-masked] (Scott Adams)
>>Date: Thu, 12 Aug 1993 15:06:23 -0400 (EDT)
>>Message-Id: <[email-masked]>
>>X-Mailer: ELM [version 2.4 PL20]
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset=US-ASCII
>>Content-Transfer-Encoding: 7bit
>>Content-Length: 8678
>>
>>Hello again,
>>
>>I had previously submitted an example of a NETBIOS connect flow.  I've
>>discovered that there were errors in that flow diagram, and I'd like
>>to fix that it and provide a more common connect flow as the primary one.
>>
>>The network looks like:
>>
>>                  +----------+                  +----------+
>>                  |          |      Tunnel      |          |
>>                  |   DLSw   +==================+   DLSw   |
>>                  |    A     |                  |    B     |
>>                  +----+-----+                  +----+-----+
>>                       |                             |
>>                  LAN  |                         LAN |
>>           -------+----+-----               ---------+---+--------
>>                  |                                      |
>>            +-----+-----+                          +-----+-----+
>>            | End Stn 1 |                          | End Stn 2 |
>>            +-----------+                          +-----------+
>>
>>First example connect flow:
>>
>>        End Stn 1         DLSw A                DLSw B         End Stn 2
>>        ---------         ------                ------         ---------
>>           |         [DISCONNECTED]       [DISCONNECTED]          |
>>           | Add_Name_Qry  |    NETBIOS_ANQ      | Add_Name_Qry   |
>>Note 1.    | ------------> | ------------------> | -------------> |
>>           |      .        |         .           |       .        |
>>           |      .        |         .           |       .        |
>>           |      .        |         .           |       .        |
>>           | Name_Qry(C)   |    NETBIOS_NQ       |  Name_Qry(C)   |
>>Note 2.    | ------------> | ------------------> | -------------> |
>>           |         [DISCONNECTED]       [RESOLVE_PEND]          |
>>           |  Name_Rec(L)  |    NETBIOS_NR       |   Name_Rec(L)  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |         [CIRCUT_ESTAB]       [CIRCUIT_PEND]          |
>>           |               |    REACH_ACK        |                |
>>           |               | ------------------> |                |
>>           |               |              [CIRCUIT_ESTAB]         |
>>           |  SABME        |    CONTACT          |  SABME         |
>>Note 4.    | ------------> | ------------------> | -------------> |
>>           |     UA  [CONNECT_PEND]       [CONTACT_PEND]      UA  |
>>           | <------------ |       .             | <------------- |
>>Note 5.    |  RR           |       .             |  RR            |
>>           | ------------> |       .             | -------------> |
>>           |          RNR  |       .      [CONNECTED]         RR  |
>>           | <------------ |     CONTACTED       | <------------- |
>>           |           RR  | <-----------------  |                |
>>           | <------------ |                     |                |
>>           |         [CONNECTED]                 |                |
>>           | Sess_Init     |   I-Frame           |  Sess_Init     |
>>Note 6.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           | Sess_Conf     |    I-Frame          |  Sess_Conf     |
>>           | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |               |                     |                |
>>
>>Note 1.  This is a broadcast Add_Name_Query intended to register its
>>         name and check for conflicts.  If no other end station is
>>         using this name and there are no name conflicts, then it
>>         assumes it can use it.
>>
>>Note 2.  This is a broadcast Name_Query Call packet that is intended
>>         to find out if the destination end station has a LISTEN
>>         outstanding for the source Name.
>>
>>Note 3.  This Name_Recognized indicates that a LISTEN was outstanding,
>>         meaning it's ok to establish a session.
>>
>>Note 4.  The SABME initiates the LLC Type 2 Connection for the NetBIOS
>>         session.
>>
>>Note 5.  I have shown what I think connection establishment would look
>>         like using the immediate UA/RNR response indicated in the
>>         RFC.  Witholding the UA could also be applied here, allowing
>>         the RNR to be dispensed with.
>>
>>Note 6.  The Session_Init packet begins the transmission of I frames
>>         over the new connection, and initiates the NetBIOS session.
>>
>>An  alternative connect sequence (seen from Windows NT) is:
>>
>>[Note that this was the sequence I provided in my original message,
>>with appropriate corrections.  There were two errors.  One was that
>>the SSP pkts sent between DLSw in response to NB_NAME_QUERY/RECOGNIZED
>>pkts after the switches enter CIRCUIT_ESTABLISHED state should be
>>DGRMFRAMEs, not NETBIOS_NQ and NETBIOS_NR.  Also, I left out the
>>REACH_ACK pkt after receipt of the NETBIOS_NR frame.]
>>
>>        End Stn 1         DLSw A                DLSw B         End Stn 2
>>        ---------         ------                ------         ---------
>>           |         [DISCONNECTED]       [DISCONNECTED]          |
>>           | Name_Qry(F)   |    NETBIOS_NQ       | Name_Qry(F)    |
>>Note 1.    | ------------> | ------------------> | -------------> |
>>           |         [DISCONNECTED]       [RESOLVE_PEND]          |
>>           |     Name_Rec  |    NETBIOS_NR       |      Name_Rec  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |         [CIRCUT_ESTAB]       [CIRCUIT_PEND]          |
>>           |               |    REACH_ACK        |                |
>>           |               | ------------------> |                |
>>           |               |              [CIRCUIT_ESTAB]         |
>>           | Name_Qry(C)   |    DGRMFRAME        |  Name_Qry(C)   |
>>Note 2.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           |  Name_Rec(L)  |    DGRMFRAME        |   Name_Rec(L)  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |  SABME        |    CONTACT          |  SABME         |
>>Note 4.    | ------------> | ------------------> | -------------> |
>>           |     UA  [CONNECT_PEND]       [CONTACT_PEND]      UA  |
>>           | <------------ |       .             | <------------- |
>>Note 5.    |  RR           |       .             |  RR            |
>>           | ------------> |       .             | -------------> |
>>           |          RNR  |       .      [CONNECTED]         RR  |
>>           | <------------ |     CONTACTED       | <------------- |
>>           |           RR  | <-----------------  |                |
>>           | <------------ |                     |                |
>>           |         [CONNECTED]                 |                |
>>           | Sess_Init     |   I-Frame           |  Sess_Init     |
>>Note 6.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           | Sess_Conf     |    I-Frame          |  Sess_Conf     |
>>           | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |               |                     |                |
>>
>>Note 1.  This is a broadcast Name_Query intended to locate the
>>         destination end station's MAC addr.
>>
>>Note 2.  This is a directed Name_Query Call packet that is intended to
>>         find out if the destination end station has a LISTEN
>>         outstanding for the source Name.
>>
>>Note 3.  This Name_Recognized indicates that a LISTEN was outstanding,
>>         meaning it's ok to establish a session.
>>
>>Note 4.  The SABME initiates the LLC Type 2 Connection for the NetBIOS
>>         session.
>>
>>Note 5.  I have shown what I think connection establishment would look
>>         like using the immediate UA/RNR response indicated in the
>>         RFC.  Witholding the UA could also be applied here, allowing
>>         the RNR to be dispensed with.
>>
>>Note 6.  The Session_Init packet begins the transmission of I frames
>>         over the new connection, and initiates the NetBIOS session.
>>
>>In both scenarios session disconnect is handled as an I frame within
>>the LLC 2 connection (SESSION_END frame), and the LLC 2 connection is
>>disconnected normally.  Once the LLC 2 connection is disconnected then
>>all remnants of the NETBIOS session are gone.
>>
>>These are how I think such connect flows are supposed to work over
>>DLS.  If I'm wrong, PLEASE correct me (particularly those at IBM,
>>who are the only ones with actual experience...).  Thanks,
>>
>>Scott
>>